The present invention relates to high-speed uplink packet access technology. In particular, the present invention relates to a serving-grant allocation method for high-speed uplink packet access systems.
Since the release of REL6, 3GPP (the 3rd Generation Partnership Project) offers high-speed uplink packet access (HSUPA: High-speed Uplink Packet Access) technology that provides high-speed transmission in air interface for uplink packets. This type of high-speed uplink packet access technology adopts Hybrid Automatic Repeat Request (HARQ: Hybrid Automatic Repeat Request) technology, base station (Node B) quick scheduling technology and uplink 2 ms short frame technology, which significantly enhances data throughput rate for uplink users. Air interface peak value speed has reached as high as 5.76 Mbps, and system uplink capacity has also improved considerably.
HSUPA is achieved through interaction between Enhanced Dedicated Channel (E-DCH), E-DCH Dedicated Physical Control Channel (E-DPCCH), E-DCH Dedicated Physical Data Channel (E-DPDCH), EDCH Hybrid ARQ Indicator Channel (E-HICH), E-DCH Relative Grant Channel (E-RGCH), and E-DCH Absolute Grant Channel (E-AGCH). These channels are pre-allocated during the process of establishment of channels in advance (they may be reallocated while calling). FIG. 1 is a HSUPA data transmission flowchart. As shown in FIG. 1, grant message is transmitted and scheduled to the user equipment (UE) over E-RGCH and E-AGCH by Node B; UE schedules Hybrid ARQ based on the grant message and transmits data over the transmission channel E-DCH. E-DCH is mapped to the physical channel and data is transmitted to Node B, and transmission indication message is transmitted over E-DPCCH to Node B. Node B receives E-DPCCH and E-DPDCH simultanueously, and decodes data on E-DPDCH according to the instruction of the transmission indication message over E-DPCCH. Then, Node B transmits reception results and uplink channel quality status to UE via E-HICH. Finally, this UE decides the next transmission on the basis of the message over E-HICH and in combination with the grant message over E-RGCH and E-AGCH.
The scheduled grant message sent from Node B to the user via E-AGCH/E-RGCH decides the HSUPA transmission resource that the mobile subscriber may use. Among these, absolute scheduling grant message is transmitted over E-AGCH, and the message may directly designate the HSUPA transmission resource that the mobile subscriber may use. Relative scheduling grant message is transmitted over E-RGCH, and after reception by the mobile subscriber, the mobile subscriber increases or decreases the currently available transmission resource according to the designated ratio. Absolute schedule grant in E-AGCH can be classified into two types: one type is the primary grant, which is identified by the primary E-RNTI (E-RNTI is the E-DCH wireless network temporary identifier, which is the identification code of the mobile subscriber in HSUPA. It is divided into the primary E-RNTI and secondary E-RNTI, and it is allocated by the SRNC during channel setup), the primary E-RNTI will be directly set in the mobile subscriber as a variable, which is called serving-grant (Serving-Grant), and the mobile subscriber is depending on the value of the variable to judge the available HSUPA transmission resource. The other type is the secondary grant, which is identified by the secondary E-RNTI. The secondary grant is set to serving-grant only under conditions where the primary identifier is unavailable. Otherwise it may be stored to the stored-secondary-grant, which is another variable in the mobile subscriber that should be set to the serving-grant in the future, when the primary identifier becomes invalid. The serving-grant value is initially allocated by the Serving Radio Network Controller (SRNC: Serving Radio Network Controller) via the wireless channel allocation or reallocation of radio resource control (RRC: Radio Resource Control) information.
The initial allocation message of the serving-grant value containing the aforementioned wireless channel allocation or reallocation of radio resource control information includes two parts: the first part is the serving-grant value, and the other is the primary/secondary grant selector, which is used to clarify whether the serving-grant value is allocated through the primary E-RNTI or the secondary E-RNTI, as shown in Table 1.
TABLE 1Serving-grant allocation message in the RRC message.>Serving-grantSelectiveREL-6>>Serving-grantRequiredIntegerThe value in tableREL-6value(0 . . . 37, 38)9.2.5.2.1.1 inTS25.321corresponding to 0-37, 38indicated value is 0.>>Primary/secondaryRequiredEnumerate:Indication serving-REL-6grant selector{“Primary”,grant is received via“Secondary”}primary E-RNTI orsecondary E-RNTI
When the mobile subscriber received the initial allocation message as shown in Table 1, the following process flow is carried out (as shown in FIG. 2).
In step S10, decide whether or not the initial allocation message contains Serving-Grant option. If serving-grant option is included, then set the variable for serving-grant to the value indicated by the serving-grant value contained in the initial allocation message (the serving-grant value contained in the initial allocation message corresponds to the indicated value. For information on correspondence relationship of values 0˜37, please refer to 3GPP TS25.321 v6.7.0 Table 9.2.5.2.1.1, value indicated by value 38 is zero-grant) (step S11), then proceed to step S12, otherwise proceed to step S15.
Step S12 decides whether the primary/secondary selector is selected as “Primary”, if it is, proceed to step S13, otherwise proceed to step S14.
Step S13 sets primary grant available variable (Primary_Grant_Available) to “True”. That is, serving-grant will be set to primary schedule grant in E-AGCH during HSUPA operation. Execute step S16.
Step S14 sets primary grant available variable to “False”. That is, serving-grant will be set to secondary schedule grant in E-AGCH during HSUPA operation. Execute step S16.
Step S15 sets serving-grant (Serving-Grant) to zero-grant (Zero-Grant) and allocates primary grant available variable to “True”. Execute step S16.
Step S16 allocates stored-secondary-grant (Stored-secondary-grant) variable to zero value.
It is clear from FIG. 2 that regardless whether or not the serving-grant value is allocated, and regardless of the Primary/Secondary selector, stored-secondary-grant is always zero value. That is, stored-secondary-grant of the mobile subscriber cannot be allocated at the time of wireless channel allocation or reallocation, and primary/secondary grant allocation can only select one out of the two by primary/secondary selector. This results in network inflexibility with regards to control and allocation of relative variables of the mobile subscribers. This, in turn, will reduce the network's capacity to exercise control over the mobile subscriber. Because, in such a case, during primary/secondary schedule grant switching, the secondary schedule grant can only be set by Node B in real time. Meanwhile, Node B must transmit an additional E-AGCH channel message to allocate the variable, which decreases channel usage, adds system-processing complexity, and reduces system performance.
In addition, there may arise the following two problems as well:
(1) When the initial allocation grant is the primary type, when switched to secondary E-RNTI during execution, serving-grant=stored-secondary-grant=0, because the initial stored-secondary-grant is 0. This probably is not what Node B preferred.
(2) When the initial allocation grant is the secondary type, the stored-secondary-grant is also 0; this differs with the process during execution. In execution, when sending the absolute grant over the secondary E-RNTI, the absolute grant value is stored in the stored-secondary-grant. Thus, after initialization, if Node B does not further transmit the grant, and if UE switched to the primary E-RNTI and again switched back to secondary E-RNTI, it may result in serving-grant value being zero-grant. In this way, UE will not be able to transmit data; this also will not be what Node B hoped for. Also, the process logic from the beginning to the end is different upon execution of the stored-secondary-grant to the same variable. From a logical protocol standpoint, this is a problem.